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[57] ABSTRACT 

A packet of data is received from a LAN and transmitted 
over a WAN, by retaining the native LAN frame format of 
the packet during transmission across the WAN. Thus, LAN 
data may be transmitted over a SONET point-to-point link 
within a WAN network without the interim steps of creating 
ATM cells or other WAN transport packaging protocols. 
Instead, the LAN data may be transmitted directly over the 
SONET link as raw data, and reconstructed directly at the 
receiving end of the SONET link. A first buffer stores data 
from the LAN so that a corresponding packet size may be 
determined, and a second buffer stores data from the WAN 
to account for any speed difference between the LAN 
circuitry and WAN circuitry. 

15 Claims, 22 Drawing Sheets 
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1 

METHOD AND APPARATUS FOR 
TRANSMITTING LAN DATA OVER A 
SYNCHRONOUS WIDE AREA NETWORK 

This is a continuation-in-part of copending and com- 5 
monly owned US. Ser. No. 08/681,313 filed on Jul 22, 
1996, from which priority is claimed and which is hereby 
incorporated by reference in its entirety. 

BACKGROUND OF THE INVENTION 10 

1. Field of the Invention 

This invention relates generally to computer networking 
systems and more particularly to transmitting data from a 
local area network over a wide area network. 15 

2. Discussion of the Related Art 

Computer networks are widely used to provide increased 
computing power, sharing of resources, and communica- 
tions between users. Local area networks (LANs) may 
include a number of computer devices within a room, 20 
building, or site that are connected by high speed data links 
such as token ring, ethernet, or the like. LANs have tradi- 
tionally been interconnected by bridges, hubs, and switches. 
A Wide Area Network (WAN) may link together different 
LANs. A WAN typically includes packet switches, micro- 25 
wave links, and satellite links. Thus, a network may include 
several hundred or more interconnected devices (nodes), 
distributed across several geographical locations, and 
belonging to several organizations. 

LANs are typically used for high speed communications 30 
with relatively few nodes, while WANs are used for con- 
necting a vast number of nodes, but generally at a slower 
speed. Therefore, LAN transport mechanisms and protocols 
are typically not appropriate for use on a WAN. ^ 

FIG. 1 shows an example of an arrangement in which a 
WAN couples together several LANs. In particular, FIG. 1 
shows WAN 10 connecting LAN A, LAN B and LAN C. A 
LAN/WAN interface 12 provides translation, data 
- formatting, and/or other protocol-related functions so that ^ 
source and destination computers on LAN A may interface 
with source and destination computers on LAN B and LAN 
C. Similarly, LAN/WAN interface 14 allows LAN B to be 
coupled to WAN 10, and LAN/WAN interface 16 allows 
LAN C to be coupled to WAN 10. 45 

One method of interfacing a LAN to a WAN is to provide 
a router-specific interface which substitutes a WAN physical 
link layer and a proprietary data link layer in each LAN data 
message, and rate-converts the LAN messages to WAN 
compatible speeds. Then the messages may be transmitted 50 
across the WAN. A drawback to such an approach is that 
many of the high-capacity networks that provide high-speed 
communications within the WAN are inflexible and expen- 
sive. Additionally, there is very limited network manage- 
ment and maintenance support capabilities, and very little, if 55 
any, spare signal capacity within frame structures, in the 
WAN protocoL Thus, this technique is generally very expen- 
sive and slow. 

SONET (Synchronous Optical Network) is a standard for 
a high-capacity optical telecommunications network. It is a 60 
synchronous digital transport system intended to provide a 
more simple, economical and flexible network infrastruc- 
ture. The Phase 1 SONET standard issued in March 1988, 
and is defined in "American National Standard for 
Telecommunications-Synchronous Optical Network 65 
(SONET) Payload Mappings", ANSI Tl,105 .02-1993 draft, 
which is incorporated by reference. 



2 

SONET may also be defined as an octet-synchronous 
multiplex scheme that defines a family of standard rates and 
formats. Despite the name, SONET is not limited to optical 
links. Electrical specifications have been defined for single- 
mode fiber, multi-mode fiber, and CATV 75 ohm coaxial 
cable. The transmission rates are integral multiples of 
51.840 Mbps, which may be used to carry T3/E3 bit- 
synchronous signals. The allowed multiples are currently 
specified as: 



STS-l 


51.840 


STS-3 


155.520 


STS-9 


466.560 


STS-12 


62X080 


STS-18 


933.120 


STS-24 


1,244.160 


STS-36 


1,866.240 


STS-48 


2,488.320 



The CCnT Synchronous Digital Hierarchy (SDH) defines a 
subset of SONET transmission rates, beginning at 155520 
Mbps, as set forth below: 



SONET SDH equivalent 

STS-3c STM-1 

STS-12C STM-4 

STS-48c STM-1 6 



As defined, SONET can be used in loop carrier, local 
network, and long haul network application areas. 

FIG. 2 is a block diagram of SONET elements coupled 
together in a direct synchronous multiplexing mode. 
SONET line signals 21 are transmitted across the SONET 
digital cross-connect system 20. SONET terminal multiplex- 
ers 22, 24 receive tributary signals 23, for example from 
source and destination computers, and provide the SONET 
line signals. 

One advantage of the SONET standard is that individual 
tributary signals may be accessed within the structure of the 
multiplexed SONET line signal. For example, SONET add- 
drop multiplexers 26 and 28 may each provide data from 
their respective tributary signals 25 onto the SONET digital 
cross-connect system 20. 

The building block of the SONET protocol is a synchro- 
nous transport frame 30, shown in FIG. 3. Frame 30 includes 
transport overhead 34, and synchronous payload envelope 
(SPE) 32. Although data is transported serially, the frame 30 
is typically represented by a two-dimensional map with N 
rows and M columns; a byte is provided at each row/column 
intersection. The signal bits are transmitted starting with the 
byte in the upper left hand corner of the frame 30, followed 
by the second byte in the top row, etc., until all of the bytes 
of the first top row are transmitted. The second and subse- 
quent rows follow transmission of the first row in the same 
manner. 

The SPE 32 includes individual tributary signals, and is 
designed to traverse a SONET network from end to end. The 
SPE 32 is assembled and disassembled only once, even 
though it may be transferred from one transport system to 
another (i.e., between several SONET network nodes) many 
times on its route through the SONET network. 

Some signal capacity is allowed in each frame 30 for 
transport overhead 34 to provide support and maintenance 
facilities, such as alarm monitoring, bit-error monitoring, 
and data communications channels. Transport overhead 34 



06/25/2003, EAST Version: 1.03.0002 



6,122,281 

3 4 

typically pertains only to an individual transport system and In one embodiment, an interface is provided between a 

is not transferred when the SPE 32 is transferred between first network and a second network, including a first mter- 

different transport systems. device, a second interface device an input buffer and 

One method of interfacing a LAN with a WAN, such as * control circuit. The fi"erfoce * vice is capable of 

10.4%. This is a relatively large amount of overhead, when ^ ^ buffer and stofes a packet ^ the 

compared to a typical LAN packet. FIG. 4 shows an ATM fifst iata fy at device A control circuit * coupled between 

cell 40, in which 48 bytes of ATM data 44 are transmitted 10 ^ fifSl intcrfacc devicc ^ thc second interface device, and 

with a 5-byle ATM header 42. In accordance with the ATM. ^ ^pigd ^th the input buffer. The control circuit deter- 

standard, an ATM cell always has 53 bytes. mines a length of the packet and provides the packet and an 

FIG. 5 shows a SONET synchronous transport frame 49 indication of the length of the packet to the second interface 

that includes ATM cells. The synchronous transport frame device. The second interface device transmits the packet and 

49 includes SPE 53 and a transport overhead 48 which 15 mc indication of thc length of the packet across the second 

includes section overhead 50, pointer 52 and line overhead network. 

51. The pointer 52 is a reference which indexes thc starting Another embodiment of the invention is directed to a 

point of the SPE 53. SPE 53 includes path overhead 54, mcmo d for transmitting data from a first network to a second 

ATM cells 55A, 55B, 55C, 55D, and 55E, and other data. nctW0 rk, comprising the steps of receiving a data packet 

During times for which there are no ATM cells to transmit, 20 from a sourcc on mc first network, buffering the packet to 

an idle space is provided (see for example idle space 56 prov ide buffered data, determining a length of the packet 

between two ATM cells 55D and 55E). In addition, because &om me bxiffered data, and transmitting the packet and an 

an integer number of ATM cells may not fit within a given md i C ation of the length of the packet across a third network 

SPE, there may be some empty space 57 (see FIG. 5) wfaich ^ couple d between the first network and the second 

following the last ATM cell, or otherwise dispersed within 25 ^ mat tn e packet is received at the second net- 

thc SPE. work. 

FIG. 6 depicts a known process for converting LAN data yet anotner embodiment is directed to an apparatus for 

to ATM cells for transport over a SONET network. In step transmitting data from a first network to a second network, 

58, a LAN packet is received from a first IAN. The LAN comprising me ans for receiving a data packet from a source 

packet is divided into 48-byte segments (step 59) in accor- 30 oq me ^ network) means for buffering the packet to 

dance with the fixed ATM cell size. An ATM 5-byte header ^ buflfered ^ mcans for determining a length of the 

is added to each of tbe 48-byle segments (step 60) to create kct from ^ buffcred da ta, and mcans for transmitting 

a number of ATM cells. Hie ATM cells are packed into a * c ^ aod ^ mdication of mc lcngth of m e packet 

SONET SPE (step 61). The appropriate SONET transport &cr< £ & ^ nctwork wMch & M bctwccn mc nrst 

overhead is then added to the SPE (step 62) to create a 35 network ^ ^ netWQrk 

synchronous transport frame. The frame may then be trans- cmbodimcntSj a buffcr may 

mittcd over the SONET-compatiblc network (step 63). * f differences between the first 

At another SONET^ mulUplcxer, the synchronous ; trans- * ^ a preamble may be 

port frame is received (step 64) 'J^ *°}™ „ transmitted along with the data, and a fill pattern may be 

overhead is removed (step. S5) to yield *e SPE. It is then 40 when there are no packets to be transmitted. The 

necessary to unpack the AHVl cells from the SPE in order to and the packet 

provide ATM cells (step 66) The ATM Reader is removed ™ * emitted as a contiguous data stream in a frame 

from each of the ATM cells (step 67). Only then may die ^ ^ to ^ ^ m Qetwork ^ packet 

LAN packet data be reconstructed from the ATM cell data transmitted by an interface device operating in a 

(step 68). The reconstructed LAN packet may then be 45 ^ ^ ^ ^ ^ ^ {om ^ 

transmitted °* io *^ n *^& c V! ^ . a sipnificant or encapsulation, other than that required to comply with a 
As is evident from FIGS. 4-6, there u a significant ^ nctworkovcrwh ich me packet is transmitted, 
amount of overhead which is required to transmit re con- * .^w^e <-,f th*. nn . vn * 
structed LAN data over a SONET network using the ATM . These and other features ^^^^J^ 
standard. This overhead includes not only signal bandwidth, 50 mvention shall appear from the following detailed descrip- 
tor example the 5-byte ATM header added for each 48 bytes * on ^ drawings. 

of data, but also significant processing time in order to BRIEF DESCRIPTION OF THE DRAWINGS 

divide the LAN packet, construct the ATM cells, and ula- pj G 1 ^ & somatic illustration of a wide area network 

mately reconstruct the LAN packet (WAN) connecting several local area networks (LANs); 

SUMMARY OF THE INVENTION 55 FIG. 2 is a block diagram showing elements of a SONET 

network; 

In a preferred embodiment of 'the present invention,^ ^ of & hroQ0US traQsport 
method and apparatus are provided for transmitting a. packet * transmitted across a SONET network such 
of LAN data over a WAN, by retaining a native LAN frame ua ™ • 
format of the packet across the WAN. Thus, data received 60 45 ™« ™*>™ m ™' 
from a LAN may be transmitted over a SONET point-to- FIG. 4 depicts the contents of an ATM cell 
pointlinkwithouithe interim steps of creating ATM cells or FIG. 5 illustrates an approach to pacing AIM cells mto 
other reformatted message units. Instead, the LAN data may a synchronous payload envelope (SPE) withm a synchro- 
be transmitted directly over the SONET link as "raw data" nous transport frame such as that shown in FIG. 3; 
(native LAN frame format) within SONET transport frames, 65 FIG. 6 is a flow diagram showing the known processsteps 
and reconstructed directly at the receiving end of the required to transmit reformatted LAN data over a SONEI 
SONET link. network using the ATM standard; 
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FIG. 7 is a high-level block diagram of an embodiment of between LAN A and LAN B without formatting the packet 

the invention, in which a SONET network provides com- data into separate cells, such as ATM cells. The point-to- 

munitions between two LANs; poiat link 75 may be a SONET link within the WAN 70, 

FIG. 8 is a block diagram of a SONET/LAN interface, whfclUs created and maintained by a communications 

such as that shown in FIG. 7; 5 depicls more delail of me SONET/LAN interface 

FIG. 9 is a flow diagram of process steps for transmitting 7 j A SONET line transceiver 80 provides a physical inter- 

a LAN packet from one LAN network to another LAN face with the SONET network. Coupled to the transceiver 80 

network across a SONET network, which may be performed ^ a SONET framer/deframer with raw data capability 82. 

by the elements of the block diagram of FIG. 8; The "raw data" capability, also referred to as "native frame 

FIG. 10 illustrates more detail of one of the steps of FIG. format" capability, means that data can be transmitted across 

9, in which the LAN packet is packed directly into a SONET the SONET network without adding additional overhead to 

synchronous payload envelope (SPE) along with a packet the data other than the overhead which is required by 

length field- SONET. Examples of overhead required by SONET include 

FIG. 11 illustrates more detail of the one step of FIG. 9, 15 transport overhead including payload pointer^ path i over- 

in which a LAN packet is unpacked from the SPE using bead including section overhead and line overhead, and 

information regard^ thelength of the LAN packet; ^XrS^ .Ttt^iSS 

FIG. 12 shows a SONET frame in accordance with an ^ lementatio F a> ^ overnead pay load pointers, 

embodiment of the present invention; automatic protection switching, parity check, alarm 

FIG. 13 shows a mapping of LAN packets onto SONET 20 ^n,^^ section overhead includes frame alignment 

SPEs according to the invention; pattern, and STS identification, and parity check. 

FIG. 14 is a detailed schematic diagram of one apparatus When a data packet is transported in its native frame 

for implementing the invention; format, this means that the data packet is still recognizable 

FIG. 15 is a flow process diagram of steps performed by 2S (arranged) as it was when transported across a LAN. 

the Transmit FIFO Write Control Logic (1402) of FIG. 14; Typically, this also means that there is no additional over- 

FIG 16 is a flow process diagram of steps performed by head interspersed within the data packet. In one 

the Transmit FIFO Read Control Logic (1410) of FIG. 14; embodiment, an interface device having ATM cell process- 

_ . , r ine capability may be operated in a mode which "bypasses 

^7 ^^tJS^^ 00 ^* < ^^S? m ^ SSSSJr^SSS?^^ » me Am cell ^ 
the Receive FIFO Write Control Ugpc :(1420) of HG. 14; 3a J»JIM c P^ ^ _g &r OT to, the d*. 

FIG. 18 is a flow process diagram of steps performed by £ ^ inVQked by a test or diagnostic 

the Receive FIFO Read Control Logic (1430) of FIG. 14; mo(Je of me SQNET framer/deframe r 82 (bypassing the 

FIG. 19 is a block diagram of another embodiment of the ATM processing), 
invention; 35 A data formatter 84 is coupled between the framer/ 

FIG. 20 is a flow process diagram of steps performed by deframer 82 and LAN media access controller 86. The 
the apparatus illustrated in FIG. 19 when transmitting data controller 86 provides an interface to the appropriate LAN,, 
to a SONET WAN; f or example LAN A or LAN B shown in FIG. 7. 

FIG. 21 is a flow process diagram of steps performed by ^\q. 9 shows the process steps by which a LAN packet is 
the apparatus illustrated in FIG. 19 when receiving data from ^ transmitted from a first LAN to a second LAN. In step 90, 
a SONET WAN; and the LAN packet is received from the first LAN. In step 91, 

FIG. 22 is a detailed schematic diagram of one embodi- the length of the LAN packet is determined, so that ulti- 
ment of the invention as shown in FIG. 19. mately the LAN packet may be unpacked on the receiving 

end. Such packet length may be defined as a number of 
DETAILED DESCRIPTION ^ bytes, but may also be defined as a number of bits, 

There are many businesses or organizations having two or or a number of 16-bit words. The LAN packet may be one 
more geographically-separated LANs between which much from an ethemet, FDDI, token ring, or other protocol. In step 
data is transmitted. FIG. 7 shows an example in which LAN 92, the LAN packet and a packet length field are packed 
Aismafirstlocadon71,suchasafirstbuilamgorcamr^is, directly into a SONET synchronous payload envelope 
and LANs B and C are in a second location 72, such as a 50 (SPE). In step 93, SONET transport overhead is appended to 
second building or campus. WAN 70 provides communica- the SONET SPE to create a synchronous transport frame. By 
tions among these and several other LANs, for example using a packet length field, it is not necessary to include 
LAN D and LAN E. In this example, LAN A is coupled to delimiters indicative of the end of packet and beginning of 
WAN 70 by SONET/LAN interface 73A, and LAN B is packet, which would typically be included if the packet were 
coupled to WAN 70 by SONET/LAN interface 73B. LAN B 55 encapsulated within another format, such as the HDLC 
is also coupled to LAN C by bridge 74. LAN/WAN interface format. HDLC encapsulation would require significantly 
76 provides communications between LAN D and WAN 70, more overhead. 

and LAN/WAN interface 77 provides communications Id step 95, the synchronous transport frame is transmitted 
between LAN E and WAN 70. Suitable LAN/WAN inter- over a SONET-corapauble network. The synchronous trans- 
faces 76, 77 are known in the art 60 port frame is received, and the SONET transport overhead is 
The first SONET/LAN interface 73A, second SONET/ then removed (step 96) to yield the synchronous payload 
LAN interface 73B, and WAN 70 provide a point-to-point envelope SPE (step 97). Because the SPE includes a packet 
communications path 75 between LAN A and LAN B. In length field, the bytes of the LAN packet may be unpacked 
essence, the SONET/LAN interfaces 73A, 73B provide a from the SPE by unpacking the appropriate number of bytes 
bridge function between LAN A and LAN B, and also an 65 as determined by the packet length field (step 98). The 
effective interface between LAN A and LAN C. The unpacked LAN packet is then transmitted onto the second 
SONET/LAN interfaces 73A, 73B transmit and receive data LAN (step 99). 
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As can be seen from a comparison of FIG. 9 and FIG. 6, 
there is much less overhead and many less steps in the 
present invention, as compared with the ATM approach. 
Because there is no fragmentation of the original packet, 
except perhaps between successive SPEs, higher transfer 
rates are achievable while using less computer resources and 
costs. Thus, transmitting a LAN data packet as a contiguous 
data stream contributes to more efficient communications. 

FIG. 10 shows more detail of an exemplary embodiment 
of step 92 of FIG. 9, in which the LAN packet is packed 
directly into a synchronous payload envelope. In step 100, a 
SONET ftamer/deframer is controlled to communicate in a 
raw data mode. In step 101, the native preamble for a first 
LAN packet is packed into a SPE, followed by a packet 
length field for the first packet (step 102). Then, the data for 
the first LAN packet is packed (step 103). If there are no 
more LAN packets available at this time, a fill pattern is 
packed into the SPE and subsequent SPEs, until a next LAN 
packet is available (step 104). The fill pattern may be 
selected to be easily distinguishable from a LAN preamble, 
as will be discussed in more detail below. Once a next LAN 
packet is available, the preamble is packed (step 105), the 
packet length field is packed (step 106), and the next LAN 
packet data is packed (step 107). 

FIG. U is an exemplary embodiment of step 98 of FIG. 
9, in which a LAN packet is unpacked from a synchronous 
payload envelope using information regarding the packet 
length. Because the SONET framer/deframer is operating in 
a raw data mode, there may not be a specific signal indi- 
cating that a new packet is being received. Therefore, in one 
embodiment of the invention, a native preamble is detected 
within the raw data that is received from the SONET 
framer/deframer (step 108). This preamble detection is usu- 
ally performed by a device that is external to the SONET 
framer/deframer, so that the SONET framer/deframer is free 
to continue receiving the stream of raw data. Generally, a 
native (LAN) preamble includes alternating ones and zeros 
transmitted serially, but it is possible to use other sequences. 
After the preamble has been detected, the packet length field 
is provided from the SONET framer/deframer. Accordingly, 
in step. 109, the packet length field is checked to determine 
the number of bytes in the LAN packet. Once the number of 
bytes in the LAN packet is known, the bytes may be 
provided to a LAN interface device (step 110). If a subse- 
quent LAN packet is not transmitted immediately after a 
previous LAN packet, then a fill pattern may be received 
from the SONET framer/deframer until a next preamble is 
detected (step 111). 

FIG. 12 shows one approach to formatting a variable 
length LAN packet into a modified form for direct trans- 
mission as raw data over a SONET network. The modified 
packet 115 includes a LAN preamble 116, packet length field 
117, and variable length LAN data packet 118. In one 
embodiment, the preamble includes 8 bytes, the packet 
length field includes 2 bytes, and the variable length LAN 
data packet may include any number of bytes as determined 
by the packet length field 117. 

FIG. 13 shows an example of how several modified LAN 
packets may be transmitted across a SONET network using 
a number of SPEs. For example, the SONET data stream 
may include a first synchronous transport frame 120, that 
includes a first SPE 121. The first SPE 121 includes path 
overhead 122 and data 123; data 123 is a combination of 
LAN data and fill data. For example, the first SPE 121 may 
include a first modified LAN packet 130, which is followed 
by fill data 131. This is an example of a case in which there 
was no data to transmit from a first LAN to a second LAN 



from the time that the first LAN packet 130 was sent until 
a second LAN packet is received. Following the fill data 131 
is a second modified LAN packet 132, which is immediately 
followed by third modified LAN packet 133. In this 
5 example, because the third modified LAN packet 133 does 
not fit within the space still available in the SPE 121, only 
a first portion 133A of the third modified LAN packet is 
included within SPE 121. 

Following the first synchronous transport frame 120 is a 
10 second synchronous transport frame 124, which includes a 
SPE 125 having path overhead 126 and data 127. The second 
SPE 125 includes a second portion 133B of the third 
modified LAN packet 133. No additional overhead is 
required to define this split between the first portion 133A 
is and the second portion 133B because in the beginning of 
each modified LAN packet is the packet length field 117, 
which determines the length of the variable length LAN 
packet to follow. Thus, when the raw data is provided from 
the SONET framer/deframer, all that is required is to count 
20 the appropriate number of bytes to follow, even if these 
bytes arc overlaid on two different synchronous payload 
envelopes, as shown in the example depicted in FIG. 13. 
Following the third modified LAN packet 133 is a fourth 
modified LAN packet 134. 
25 FIG. 14 is a detailed illustration of a SONET/LAN 
interface 73. In this embodiment, a "LAN to Raw Data/ 
Framer" (LRDFRMR) 140 provides an interface between a 
"Switched LAN Media Access Controller" (SLMAC) 142 
and a "Raw Data to SONET Framer" (RDSFRMR) 143. The 
30 RDSFRMR 143 is further coupled to a "Parallel/Serial and 
Serial/Parallel Converter with Clock Synthesizer" 145, 
which is further coupled to "Fiber Optic Transceiver" 146 
and "Reference Clock" 147. The transceiver 146 interfaces 
with a SONET network 138, while the SLMAC 142 inter- 
35 faces with a LAN 139. Additionally, "Host Processor 144 
provides control functions to coordinate the functionality of 
several of the elements of FIG. 14. 

In this embodiment, the RDSFRMR 143 is a 622 Mbits/ 
sec SONET Framer, Part No. PM5355, available from 
PMC-Sierra, Burnaby, British Columbia, Canada; the LRD- 
FRMR is a 20K field programmable gate array, Part No. 
A32200BX, available from Actel, Sunnyvale, Calif., U.S A.; 
the Converter 145 is Part No. VCS8110, available from 
Vitesse, Camarillo, Calif., U.S.A.; and the Fiber Optic 
45 Transceiver 146 is Part No. HFBR5207, available from 
Hewlett-Packard, Burlington, Mass., U.S.A. The Host Pro- 
cessor 144 may be any general purpose processor, and the 
SLMAC 142 may be any device which provides appropriate 
interface with a LAN. 
50 The LRDFRMR 140 may also be implemented as a 
processor, any combination of firmware or software, or may 
be embodied as an ASIC or combination of discrete ele- 
ments. The components of the LRDFRMR 140 depicted in 
55 FIG. 14 are described below. 

The Transmit FIFO Write Control Logic 1402 provides an 
interface with SLMAC 142 when data has been received 
from the LAN 139 by SLMAC 142. In particular, Transmit 
FIFO Write Control Logic 1402 interfaces with a Transmit 
60 Packet Size Counter 1404 and a Transmit FIFO 1406. The 
Transmit FIFO Write Control Logic 1402 utilizes a clock 
emanating from a Clock Buffer 1408, which receives clock 
signals from SLMAC 142. 

the Transmit FIFO Read Control Logic 1410 provides 
65 data, that has been previously processed by the Transmit 
FIFO Write Control Logic 1402, to the RDSFRMR 143. 
Such data may be particularly provided by Transmit Register 
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1412 Multiplexer 1414 selects specific data from the Trans- (Tnasnil FIFO Not Full). During this Ume i ^ P»oAc 

mit FIFO 1406, and Multiplexer 1416 selects either data transmit pulse » ™»Dy asserted, by ^ur^g the 

S- the Transmit FIFO 14^6 or fill pattern data from the ^^^*2£g^S?J& 

Fill Pattern Data Generator 1418. the Transmit FIFO 1406 is transferred to the RDSFRMR 143 

The Receive FIFO Write Control Logic 1420 provides ^ ^ Multiplexers 1414, 1416, and Transmit Register 

control when data is received from the SONET network via 1412 

the RDSFRMR 143. In particular, the Receive FIFO Write Onrmg step 162, status bits of the Transmit FIFO 1406 are 
Control Logic 1420 controls the Preamble Detect Logic m0D it 0 red to determine the end of the packet as indicated by 
1422, the Receive FIFO 1424, and the Receive Packet Size sign&1 END0 FPKT. Additionally, during step 162, the peri- 
Counter 1426. odic transmit pulse is also generated, step 163, to maintain 

Hie Receive FIFO Read Control Logic 1430 then controls me RDSFRMR 143 running in the raw data mode. At the end 

the Receive FIFO 1424, and the Receive Register 1432, to of me packet, the Transmit FIFO Read Control Logic 1410 

provide the received data to SLMAC 142. checks to see if any transmit errors occurred (step 164). If no 

Exemplary operation of the structure depicted in FIG. 14 errors occurred, then the last word of the data packet is sent 

will be explained with respect to operation of each of the to the RDSFRMR (step 165). If there is an error, the fill 

Control Logic Elements 1402, 1410, 1420, and 1430. In pattern from the Fill Pattern Generator 1418 is sent to the 

particular, FIG. 15 is a flow process diagram of steps RDSFRMR 143, as shown in step 166. After the final word 

performed by the Transmit FIFO Write Control Logic 1402. is written in either step 165 or 166, then the process returns 
The process begins by waiting for the SLMAC 142 to start ^ to step 161 which provides a fill pattern to the RDSFRMR 

a data transfer (step 150). This may be determined as an 143. 

initial state by providing a reset signal. Upon receipt of a pic. 17 illustrates the process steps performed by the 

Transmit Enable Signal (TXEN) from the SLMAC 142, the Receive FIFO Write Control Logic 1420, to receive data 

Transmit FIFO Write Control Logic 1402 begins to load the from the SONET network via RDSFRMR 143. The process 
data received from the LAN into the Transmit FIFO 1406, ^ begins when the RDSFRMR 143 provides an indication that 

step 151 In one embodiment, the SLMAC 142 also provides ft has data. For example, this may be indicated by the 

an indication of the packet size of the LAN packet. assertion of a Receive FIFO Not Empty Flag Signal 

Accordingly, in step 152, the packet size word received from (RFFNempL). At this point, as shown in step 170, data is 

the SLMAC 142 is loaded into the Transmit Packet Size rea d from the RDSFRMR 143. In step 171, the Preamble 
Counter 1404. Alternatively, the packet length of a LAN M Detect Logic 1422 monitors the sequence of data being read 

packet may also be determined within the LRDFRMR 140. to determine whether there is a preamble. If a preamble is 

In step 153 the Transmit Packet Size Counter 1404 is not detected, then data may simply be discarded as shown m 

decremented while data is written to the Transmit FIFO step 172. If, however, there is a preamble detected, then the 

1406 Such operation would typically continue until the process proceeds to step 173 in which the preamble is loaded 
packet count reaches zero, indicated by PKT CNT-0. 35 into the Receive FIFO 1424. Additionally, tte ptcto » 

However if there is a transmit error, or if the Transmit FIFO word, previously referred to as Packet Length Field 117 is 

becomes full, the process may proceed to step 154 in which loaded into the Receive FIFO 1424, as well as the Packet 

an Error Latch is set. Then, if the Transmit FIFO is full, step Size Counter 1426, step 174. 

155 shows that data is written even though the Transmit to step 175, the words of the data received from the 
FIFO 1406 is full. In one embodiment, the data is actually 40 RDSFRMR 143 are loaded into the Receive FIFO 1424 

discarded in step 155. From step 155, if the Transmit FIFO while decrementing the contents of the Packet Size Counter 

1406 is not still full, then the process can proceed to step 153 1426 and monitoring if it has expired to a count of zero, 

again. Alternatively, if the packet count reaches zero prior to which indicates the end of the packet has been reached. In 

the Transmit FIFO 1406 becoming full, than the process this example, the data is received from the RDSFRMR 143 
proceeds to step 156. 45 as 16-bit words. Various error indications may also be 

In step 156 the Transmit Error Latch (TXER) is accessed monitored during step 175. For example any error flags 

todeSe^ Prided by the RDSFRMR may be momtored. 

noerror,menmstepl57,twobitsofmeTransmitFIFOmay Additionally, the ^ceiveRFO Empty Flag of he W>S- 

be s^ to indicate that the data transfer was successful. FRMR may be monitored (RFFNempL), as well as the full 
Ste'ativelt transmit error, then two bits 50 flag of the Receive FIFO ^424 (RXFFflag). If «therofthese 
from the Transmit FIFO may be set to indicate that an error FIFO flags are set, then the process may proceed to step 176, 
occurred, step 158. After either step 157 or step 158, the in which a Receive Error Utch is set, and 
process returns to step 150, in which the system awaits new in which the process waits until me contente of the Packet 
dlTom the LAN via the SLMAC 142. Size Counter 1426 decrements. Once there = » «» »«e datt 

mn 16 demcts steps of a process performed by an 55 to be loaded, as indicated by the contents of the Packe Sue 
FIG. 16 depicte ^J^^^S^J^^^ jLic Counter 1426 being equal to zero, the Receive Error Latch 

B5SSsra=KS:sssr- Ssrsf-'"" ,,M "" 

cause the RDSFRMR 143 to provide a fill pattern in each proceeds back to step 170. 

su^ve SP^Tdes«Ld previously. Duriog step 161, 65 FIG. 18 shows the process steps performed by the Receive 
iSmoStored JdetermineXtber FIFO Read Control Logic 1430. Inmally, as shown in step 
ffe^TSndfaJed by an assertion by signal TXFFNEFL 181, the process is idle untxl a S1 gnal ts recewed mdicaUng 
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that the Receive FIFO is not empty (RXFFNEMPL). Once 
such a signal is received, in step 182, a signal may be 
provided to the SLMAC 142 to indicate that there is valid 
data which is being received from the RDSFRMR 143 by the 
LRDFRMR 140. In the example shown in FIG. 14, this is the 
Signal RXD V. Also, during step 182, the data which is in the 
Receive FIFO 1424 is provided to the SLMAC 142 via the 
Receive Register 1432. As indicted with respect to FIG. 17, 
the Receive FIFO 1424 may contain error bits indicating 
whether an error has occurred during the reception of data 
from the RDSFRMR 143. Accordingly, these error bits are 
checked in step 184. If there is no error, than in step 185 the 
final word of the data packet is sent to the SLMAC. 
Alternatively, if there was an error bit set, then a fill pattern 
may instead be sent to the SLMAC and a Receive Error 
Signal may be inserted (RXER) to the SLMAC 142, as 
shown in step 186. Following cither step 185 or 195, the 
Receive Data Valid Signal RXDV may be deasserted. 

As described above, some SONET Framcrs/Deframers 
may provide a native format transmit capability, as well as 
other transmit capabilities (e.g., ATM cell framing). In a 
particular embodiment that implements the SONET Framer/ 
Deframer as PMC-Sierra Part No. PM5355, an option is 
provided in which ATM cell processing is disabled and raw 
data is either inserted or extracted to or from the SONET 
payload. To use the PM5355 in this mode, several register 
bits may be set to the respective values shown below: 



20 



Bits 




Register Name 


Value 


CDDIS 


0x5C 


RACP GFC/Misc. Control 


1 


HCSADD 


0x50 


RACP Control 


0 


HCSPASS 


0x50 


RACP Control 


1 


HCSB 


0x60 


TACP Control 


1 


HCSADD 


0x60 


TACP Control 


0 


HCSPASS 


0x60 


TACP Control 


X 


PASS 


0x50 


RACP Control 


1 
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Such functionality may also be designed into a single 
ASIC which encompasses the functionality of the RDS- 
FRMR 143 and the LRDFRMR 140 shown in FIG. 14. 
Similarly, the functions described above may be allocated to 
any of several architectural elements and combinations of 
hardware, software and firmware. For example, all or any 
portion of the functionality described with respect to FIG. 14 
may be implemented as a general purpose processor which 
runs software to provide such functionality. 

FIG. 19 illustrates another embodiment of the invention, 
in which a data framer 192 determines the packet size of a 
packet to be transmitted, so that this function need not be 
performed by a media access controller. As with the earlier 
examples, the packet size may be defined in one embodi- 
ment as a number of bytes. As illustrated in FIG. 19, the data 
framer 192 also provides synchronization between a SONET 55 
framer/deframer 191 and a media access controller 193, so 
that these two devices may operate asynchronously and at 
different speeds. 

FIG. 19 depicts more detail of this alternative SONET/ 
LAN INTERFACE 73* (similar to interface 73 in FIG. 8). A 
SONET line transceiver 190 provides a physical interface 
with the SONET network. Coupled to the transceiver 190 is 
a SONET framer/deframer 191. At the opposite end, a LAN 
media access controller (MAC) 193 has one interface 
coupled to the LAN. "LAN to raw data framer" 
(LRDFRMR) 192 provides the interface between the framer/ 
deframer 191 and the MAC controller 193. 



In this embodiment, LRDFRMR 192 includes a transmit 
buffer 194 and transmit packet size control module 195. The 
control module 195 receives a LAN packet from MAC 
controller 193, and transmits the packet to buffer 194 where 
it is stored. The control module 195 determines the size of 
the LAN packet once it has been completely stored in buffer 
194. Such a feature eliminates a need for the MAC controDer 
193 to determine the size of the LAN packet and to append 
the packet length field to the LAN packet. LRDFRMR 192 
also includes a receive buffer 196 that receives SONET 
packets from the SONET framer/deframer 191, via receive 
synchronization module 197. In the event that the SONET 
framer/deframer 191 and the MAC controller 193 operate 
asynchronously or at different speeds, the receive buffer 196 
stores at least a portion of the SONET packet prior to it being 
15 passed to the MAC controller 193, so that module 197 may 
provide the received packet at the appropriate speed and 
time to the MAC controller 193. 

FIG. 20 is a process flow diagram of transmit mode 
operation of LRDFRMR 192. In step 201, LRDFRMR 192 
begins receipt of a LAN packet from the MAC controDer 
193. In step 202, LRDFRMR 192 begins storage of the LAN 
packet into the transmit buffer 194. While the LAN packet 
is being stored in buffer 194, a counter is incremented (step 
203). In one embodiment, MAC controller 193 generates a 
transmit enable signal TXEN while sending the LAN packet. 
While this signal is asserted data from the MAC 193 is 
stored in the buffer 194, and the control module 195 incre- 
ments the counter to monitor the size of the LAN packet 
being stored. Once the LAN packet has been completely 
stored in buffer 194 (which may be indicated by the TXEN 
signal being de-asserted), the counter value may be used as 
the packet length (step 204). Once the packet length has 
been determined, a preamble, packet length and the LAN 
packet data itself may be transmitted to the SONET framer/ 
deframer 191 (step 205). 

Operation in the receive mode of the LRDFRMR 192 is 
illustrated in FIG. 21. In step 210, the receive synchroniza- 
tion module 197 detects a SONET packet in the raw data that 
is received from the SONET framer/deframer 191. In one 
embodiment, the SONET data rate is 155.52 bits/sec, which 
yields an effective rate of 19.44 Mbytes/sec at a continuous 
rate. However, the effective data rate which an exemplary 
MAC controller may receive data is only 12.5 Mbytes/sec. 
Therefore, it may be advantageous to provide a buffering 
mechanism such as buffer 196 to allow for this data rate 
difference. Thus, in step 210, the SONET packet in the raw 
data is received from the SONET framer/deframer 191 at a 
first data rate. In step 212, the receive synchronization 
module 197 begins storing the packet in the receive buffer 
196 as the data is being received from the SONET framer 
191. As with earlier embodiments, the detection of the 
packet may be performed by a preamble detector. In step 
214, the synchronization module 197 transfers data from the 
receive buffer 196 to the MAC controller 193 at a second 
data rate that is compatible with the MAC controller 193, 
until all of the packet is transmitted. 

In one illustrative embodiment, the SONET framer/ 
deframer 191 is a PMC Sierra device (Part No. PM5347), 
each of the transmit buffer 194 and the receive buffer 196 is 
a 4Kx8 First In, First Out (FIFO), and the transmit packet 
size control module 195 and the receive synchronization 
module 197 are both implemented within an Actel one-time 
field programmable gate array (FPGA) with 20,000 gates 
(Part No. 32200 DX-1). With FIFOs of this size, this 
embodiment can support packet lengths of 4096 bytes of 
Fast Ethernet packets (100 M/bytes/sec) over a SONET STS 
3-C fiber at 155 Mbytes/sec. 
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FIG 22 is a detailed illustration of the alternative In the receive mode, preamble detect logic 250 detects 
SO^T^interface 73'; in particular, detail is provided that a preamble has been received * <^^^ 
regarding a FPGA or ASIC (Application Specific Integrated ing data with a known preamble value and detects that a 
Circuit) embodiment of the transmit packet size control start of a packet has been received by comparing the 
module 195 and the receive synchronization module 197 of 5 incoming data with a known Start Of Field (SOr) delimiter 
FIG 19 value. Preamble register REG 1 (251) stores the known 

In this embodiment, an ASIC 220 provides an interface preamble value (e.g., 55H) and preamble register REG 2 
between a MAC controller 222, which is also coupled to a (252) stores the known SOF value delimiter (e.g., SDH), so 
LAN 221, and a "Raw Data to SONET Framer" that the preamble detect logic can access these registers for 
(RDSFRMR) 223. The ASIC 220 referred to herein may be 1Q ^own values. The preamble detect logic also activates 
implemented as an FPGA or an ASIC, or as a combination ^ rece i ve write (RX WR) state machine 253, The packet 
of discrete devices. In at least one embodiment it is implc- Jength field> typically follows the SOF delimiter, is 

mented as a one-time programmable FPGA. In another stored in a receive write (RX WR) counter 254, which data 
embodiment, it is implemented as a re-programmable FPGA may ^ ^ pr0 vided to the RX WR state machine 253. 
and is further coupled to a non-volatile memory device and is ^ ^ da(a fc sU)red in lfae rece i ve pipo 228 via 
circuitry to program the re-programmable FPGA from the register req $ (255), multiplexer MUX 3 (256), and 
memory device upon power up of the circuit. register REG 9 (257). Once there is data in the receive FIFO 

The RDSFRMR 223 is further coupled to a fiber optic ^ {b& receive tea A (rx RD) counter 258 controls the 
transceiver 224, which provides an interface to the SONET motive FIFO 228 to provide the receive packet data to the 
network 218. A reference clock 225 is also coupled to the 2Q MAC 222 yia ^gstcx REG 10 (259), multiplexer MUX 4 
RDSFRMR 223, and provides a 19.44 MHz reference (260), register REG 11 (261), multiplexer MUX 5 (262), and 
Additionally, a second reference clock 226 provides a 25 register REG 12 (263). The RX RD counter 258 may also 
MHz reference to the ASIC 220. In this embodiment, a 4Kx8 ^nlxA MUX 4 (260) to provide the preamble from pre- 
transmit FIFO (TXFIFO 227) provides the functions of the amWe R£G ± and the SOF delimiter from preamble 
transmit buffer 194 of FIG. 19, and a 4Kx8 receives FIFO ^ ^ % Regis ter REG 11 (261), together with multi- 
(RXFIFO 228) provides the functions of the receive buffer plexef MUX 5 (262), provides a translation from 8-bit bytes 
196 from FIG. 19. . . to 4-bit nibbles. 

As with earlier embodiments, the functionality shown in ^ mdicated ^ pjo. 22, various registers and additional 
FIG. 19 may alternatively be provided by discrete circuitry, ^ qq many of ^ multiplexers may be used in combi- 
by software modules operating on a general purpose or a 30 nalion to provide diagnostic capability for various segments 
special purpose computer, or any combination thereof. of ^ 22Q 

In operation, a ^-bit Converter 229 within ASIC 220 Havin g thus described at least one illustrative embodi- 
receives LAN packets from the MAC controUer 2^, and ^ ^ invention, various modifications and improve- 

provides this data through the Multiplexer TXWRDPMUX wiU feadily Q0Cur t0 skil]ed m the art and are 

230 and register REG 1 (231) to the transmit FIFO 227. 35 intended to be ^thin the scope of the invention. 
While the packet is being loaded, the transmit right JJX Accordingly, the foregoing description is by way of example 
WR) state machine 232 controls a 16-bit counter 233 to ^ qoi mtended to be ^ting. 

increment while the packet is still being stored (1*., whrie ^ ^ c]aimcd ^ 

transmit enable TXEN is asserted). The Vs-bit Converter 229 ± ^ apparatus for transmitting data in packets having a 
also translates the 4-bit nibbles received from MAC con- 40 fot format dictated by a fct protocol from a first network 
troller 222 into 8-bit bytes using register A rc gff r ? to a second nct work, comprising: 

(235), and input register INREG (236). Once the data is receiving a first packet of data in the first format 

loaded, the value » the £bit counte r 2» m a « the fi P Rt network, the first packet of 

packet count queue FIFO 237, and also m the transmit read 

OX RD) state machm^^ 45 ^ fot to , ^ packetof 

mav be orovided to the RDSFRMR through the MUX 1 so dat ^- ana ... ... « „ 

miWnd RFO output register (JX FIFOOUT means for transmitting the second packet across a third 

RECrt 242 Sixer MUX 1 (241) also provides the network which is a SONET network and is coupled 

2.2. tot tet^S FIFO 227 via toe transmit between the first network and the second network so 

Firo input reSer 239 and also provides a fill pattern from that the second packet is receded at the second net- 

the fill pattern register 243 when desirable. 55 work. 

tonally, ifan error is detected in toe data stored in 2. The apparatus of ehun 1, wherein: 

theteansmit FIFO 242, then a bit may be set in a transmit the first network is a local area network, and 

error reeister (TXERR REG) 244, which in turn controls the the means for receiving includes means for receiving me 

multiplexer MUX 1 (241), to receive inverted data for the first packet from the local area network m a frame 

lastbVte of the packet data, which will in turn cause a CRC 60 format which is natrve to the local area network, 

mor when me Jacket U ultimately received. 3. The apparatus o cUuml, further compnang near*for 

Once the TX RD down counter 245 has reached a value buffering the first packet of data toprw.de buffered data and 

of Z, teSS stTrSne 238 determines that the means for determining the length of the first packet based 

t,*« c fc.r pTPn 111 has been emotied The transmit receive upon the buffered data. 

2£S££^^ diode^U-Ds) to indi- sion rate difference between .be first and second networks 

cate that data is being either transmitted or received. and further comprising: 
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second means for receiving a third packet of data from a 8. The method of claim 6, further comprising a step of 

source on the second network; determining a packet length of the variable length packet. 

means for buffering the third packet to account for the rate 9. The method of claim 8, wherein the step of determining 

difference; and the packet length includes receiving and storing the variable 

second means for transmitting the third packet to a 5 length packet in an input buffer. 

destination on the first network over the second net- io, The method of claim 6, wherein there is a transmission 

work. rate difference between the first and second networks and 

5. The apparatus of claim 1, wherein the means for further comprising a step of receiving the packet from the 
transmitting includes means for transmitting a fill pattern ^ first al a first rate and wherein the step of trans- 
across the third network when no packets are received from miltill g ^ at a second rate. 

the first network. 11 The method of claim 10, wherein the step of trans- 

6. In a computer-implemented method for transmittmg 11 inc ™ luou U1 ' . * . fi 
packet data reeved from a first network in a native LAN mittmg includes a step of buffenng data from the first 
format across a second network in a synchronous transport network to account for the rate difference. 

frame, the frame including a transport overhead and a 15 12. The method of claim 10, further comprising a step of : 

synchronous payload envelope (SPE), the method compris- transmitting the synchronous transport frame to a desti- 

ing the step of: nation on a third network over the second network, 

transmitting a variable length packet received from the ^ metrjOC i c f claim 6, further comprising the step of 
first network over the second network in the synchro- 2Q rccciving ^ synchronous transfer frame at a third network, 

nous transport frame, where the SPE of the synchro- Qf djdm ^ wbefein ^ step of receiving 

nous transport frame further mcludes a packet length ^ ^ iitom 

field and the variable length packet m the native LAN ^^J^ Uansport ^ 
T.K^ofdai^ 25 15.Tliememc<lofclaiml3,wheremmetin^networkis 

a a step of transmitting a fill pattern when there are no a LAN. 
pending frames to be sent in the synchronous transport 
frame. 
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